User Stories — Product Backlog
AquaX — Shrimp Farming Management Platform
| Document Info |
|
| Version |
1.0 |
| Status |
Draft — Product Backlog Baseline |
| Created Date |
2026-09-17 |
| Last Updated |
2026-09-17 |
| Owner |
Product |
| Reviewers |
Engineering, QA, Design, Business |
| Source Documents |
01_PRD — Product Requirements Document.md, 02_BRD — Business Requirements Document.md, 03_SRS — Software Requirements Specification.md, 05_Permission Matrix.md, 01-product/roadmap.md |
Implementation alignment note: This backlog distinguishes current partial implementation from planned roadmap work. PARTIAL stories may already have backend/web/mobile support but still need hardening, parity, tests or product decisions before being accepted as done.
Table of Contents
- Purpose And Scope
- Backlog Conventions
- Personas And Role Mapping
- MVP / Release Mapping
- Epic Overview
- Product Backlog
- Non-Functional And Platform Stories
- AI Safety And Prediction Backlog
- Open Decisions And Blockers
- Definition Of Ready And Definition Of Done
- Traceability
- Document History
1. Purpose And Scope
This document converts the current AquaX PRD, BRD, SRS and permission matrix into a product backlog. It is intended for product planning, sprint slicing, QA preparation and release scope discussion.
The backlog covers:
- authentication, users, role and scope management;
- farm, pond and crop management;
- water monitoring, alerts and notifications;
- feeding, farming logs and productivity;
- reports and Excel export;
- ticket/incident management;
- IoT device control and automation;
- Farming Handbook;
- AI chatbot, AI recommendations and AI prediction;
- security, auditability, performance, offline and operational quality.
This backlog does not assign delivery dates. Target dates remain TBD until project planning is approved.
2. Backlog Conventions
2.1 Story ID Format
| Prefix |
Meaning |
US-AU-* |
Authentication and user management stories. |
US-FP-* |
Farm, pond and crop stories. |
US-WM-* |
Water monitoring stories. |
US-AL-* |
Alert stories. |
US-FD-* |
Feeding stories. |
US-LOG-* |
Farming log and productivity stories. |
US-RP-* |
Report and export stories. |
US-TK-* |
Ticket and incident stories. |
US-IOT-* |
IoT/device stories. |
US-HB-* |
Farming Handbook stories. |
US-NO-* |
Notification stories. |
US-SC-* |
System configuration stories. |
US-AI-* |
AI/chatbot/recommendation stories. |
US-AIP-* |
AI prediction stories. |
US-NFR-* |
Non-functional/platform quality stories. |
2.2 Priority
| Priority |
Meaning |
P0 |
Critical for MVP acceptance, security, scope isolation or core operations. |
P1 |
Important product capability expected in MVP or near-term release. |
P2 |
Useful enhancement, workflow parity or automation. |
P3 |
Future or optional capability. |
2.3 Status
| Status |
Meaning |
PARTIAL |
Implemented in part or present in current code but not fully accepted. |
PLANNED |
Valid requirement but not implemented in current code. |
TBD |
Needs product/domain/technical decision before story can be finalized. |
FUTURE |
Out of current MVP 1-4 scope. |
2.4 Story Template
Stories are written in this format:
As a [role],
I want [capability],
so that [business/user value].
Acceptance criteria are intentionally concise. Detailed test cases belong in 06-testing/test-cases.md.
3. Personas And Role Mapping
| Product Persona |
Backend/Mobile Role |
Main Backlog Interest |
| System Administrator |
ADMIN |
Users, farms, ponds, devices, settings, reports, handbook administration and permission hardening. |
| Farm Owner / Chủ hộ |
OWNER |
Farm/pond visibility, alerts, reports, tickets, feeding/log review, device actions if enabled and AI support. |
| Manager |
MANAGER |
Operational management for assigned farms/ponds where enabled. Current web/mobile coverage is partial. |
| Pond Technician / KTV |
TECHNICIAN |
Assigned pond operations, quick logging, alert/ticket handling, field notifications and mobile workflows. |
| Product / Business Owner |
N/A |
Roadmap, acceptance, formulas, thresholds, SLA, AI safety and release decisions. |
4. MVP / Release Mapping
| Stage |
Backlog Theme |
Status |
| MVP 1 |
Auth, roles/scope, farm/pond foundation, six-metric dashboard, basic environmental alerts, device on/off, command history, technical ticket and email. |
PARTIAL |
| MVP 2 |
Feeding entry, manual pH/alkalinity/minerals/siphon logs, reports, Excel export, KTV assignment and basic handbook. |
PARTIAL |
| MVP 3 |
Rule-based energy optimization, device runtime analysis and text chatbot from handbook/pond data. |
PARTIAL / PLANNED |
| MVP 4 |
AI feeding, feeding-time prediction, growth/productivity assessment, PCR/FCR/productivity analysis and image chatbot. |
PLANNED |
| Future |
SMS/Zalo/calls, SSO/OAuth, ERP/supply-chain integration, advanced traceability and realtime camera AI. |
FUTURE |
5. Epic Overview
| Epic ID |
Epic |
Goal |
MVP |
Status |
| EP-01 |
Authentication, Users And Scope |
Secure role-based access across web/mobile/API. |
MVP 1 |
PARTIAL |
| EP-02 |
Farm, Pond And Crop Operations |
Maintain operational structure for all farm workflows. |
MVP 1 |
PARTIAL |
| EP-03 |
Water Monitoring |
Display water metrics, sensor state, context and history. |
MVP 1 |
PARTIAL |
| EP-04 |
Alerts And Notifications |
Detect abnormal conditions and route follow-up. |
MVP 1-2 |
PARTIAL |
| EP-05 |
Feeding Management |
Capture feed operations and prepare recommendation data. |
MVP 2-4 |
PARTIAL / PLANNED |
| EP-06 |
Farming Logs And Productivity |
Capture daily operational data and crop productivity. |
MVP 2-4 |
PARTIAL |
| EP-07 |
Reports And Excel Export |
Support scoped operational reporting. |
MVP 2 |
PARTIAL |
| EP-08 |
Tickets And Incidents |
Manage technical issues from creation to closure. |
MVP 1-2 |
PARTIAL |
| EP-09 |
IoT Device Control |
Manage device state, command history and automation. |
MVP 1-3 |
PARTIAL |
| EP-10 |
Farming Handbook |
Provide approved operational knowledge. |
MVP 2-3 |
PARTIAL |
| EP-11 |
AI Decision Support |
Chatbot, recommendation, prediction and safety controls. |
MVP 3-4 |
PLANNED |
| EP-12 |
Platform Quality |
Security, audit, performance, offline, operations and release quality. |
MVP 1-4 |
PARTIAL / PLANNED |
6. Product Backlog
6.1 EP-01 — Authentication, Users And Scope
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-AU-001 |
As a user, I want to log in with email and password, so that I can access role-appropriate AquaX features. |
P0 |
MVP 1 |
PARTIAL |
Valid user lands on correct role home; invalid credentials are rejected; disabled users cannot log in. |
FR-01-001, AC-01 |
| US-AU-002 |
As a user, I want to log out safely, so that my session cannot be reused on the device. |
P0 |
MVP 1 |
PARTIAL |
Token/session state is cleared; user returns to auth flow. |
FR-01-002 |
| US-AU-003 |
As a user, I want password recovery, so that I can regain access without admin intervention. |
P1 |
MVP 1 |
PARTIAL |
Reset email is sent; token expiry follows configured policy; used/expired token is rejected. |
FR-01-003 |
| US-AU-004 |
As an admin, I want to create and edit users with roles, so that the organization can onboard operators safely. |
P0 |
MVP 1 |
PARTIAL |
Admin can create user with MANAGER, TECHNICIAN or OWNER; role values match backend enum; duplicate email is prevented. |
FR-01-004 |
| US-AU-005 |
As an admin, I want to disable users instead of deleting history, so that operational traceability is preserved. |
P0 |
MVP 1 |
PARTIAL |
Disabled user cannot log in; historical records still show the actor. |
FR-01-004, BRD-008 |
| US-AU-006 |
As an admin, I want to assign farm/pond/ticket scope, so that users see only authorized data. |
P0 |
MVP 1 |
PARTIAL |
User can access assigned scope only; cross-scope API requests are denied. |
FR-01-005, NFR-05 |
| US-AU-007 |
As a farm owner or manager, I want to assign technicians to ponds where permitted, so that field tasks go to the correct KTV. |
P1 |
MVP 2 |
PARTIAL |
Assigned technician sees assigned ponds; unassigned technician cannot access pond detail. |
FR-01-006, FR-02-004 |
| US-AU-008 |
As a security owner, I want user and permission changes audited, so that sensitive access changes are traceable. |
P0 |
MVP 1 |
PARTIAL |
Audit/activity log includes actor, action, target, timestamp and relevant before/after data where supported. |
FR-01-008, NFR-13 |
| US-AU-009 |
As a product owner, I want backend scope bypasses removed, so that permission acceptance can be trusted. |
P0 |
MVP 1 |
PARTIAL |
Temporary bypass areas are hardened; permission regression tests cover negative cases. |
Permission Matrix, AC-01 |
6.2 EP-02 — Farm, Pond And Crop Operations
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-FP-001 |
As an admin, I want to create and maintain farms, so that AquaX reflects real farm operations. |
P0 |
MVP 1 |
PARTIAL |
Farm has required metadata, owner/status and appears in scoped lists. |
FR-02-001 |
| US-FP-002 |
As an admin or authorized manager, I want to create and update ponds under farms, so that pond operations can be tracked. |
P0 |
MVP 1 |
PARTIAL |
Pond stores code/name, area, stocking context and farm relation; invalid farm is rejected. |
FR-02-002 |
| US-FP-003 |
As an operator, I want pond detail to show current crop context, so that daily decisions use the active crop. |
P0 |
MVP 1 |
PARTIAL |
Detail shows active crop/farming day/shrimp size where available. |
FR-02-003, FR-03-007 |
| US-FP-004 |
As an admin, I want to manage crop cycles per pond, so that each production cycle is traceable. |
P1 |
MVP 1 |
PARTIAL |
One active crop rule is enforced or clearly handled; closed crops remain visible. |
FR-02-003 |
| US-FP-005 |
As a business owner, I want closed crop data protected, so that historical production data is not accidentally changed. |
P0 |
MVP 2 |
PARTIAL |
Closed crop edits are blocked or require privileged override and audit. |
FR-02-007, BR-Closed Crop |
| US-FP-006 |
As an admin, I want to assign sensors and devices to ponds, so that monitoring and commands are linked to the right pond. |
P0 |
MVP 1 |
PARTIAL |
Assigned sensor/device appears in pond context; reassignment is audited where supported. |
FR-02-005 |
| US-FP-007 |
As an owner, I want a farm and pond list with health/alert status, so that I can quickly identify ponds needing action. |
P0 |
MVP 1 |
PARTIAL |
List respects scope and shows alert/sensor/device summary. |
FR-02-006, FR-03-001 |
6.3 EP-03 — Water Monitoring
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-WM-001 |
As an owner, I want a farm dashboard with pond alert status, so that I can prioritize daily checks. |
P0 |
MVP 1 |
PARTIAL |
Dashboard includes only scoped farms/ponds and shows alert status. |
FR-03-001 |
| US-WM-002 |
As an operator, I want to view pH, DO, salinity, algae/ORP, alkalinity and temperature, so that I can assess pond conditions. |
P0 |
MVP 1 |
PARTIAL |
Each metric shows value, unit, timestamp and status color where data exists. |
FR-03-002 |
| US-WM-003 |
As an operator, I want historical charts by 24h, 7d, 30d and custom range, so that I can spot trends. |
P1 |
MVP 1 |
PARTIAL |
Selected range changes displayed series; empty data state is clear. |
FR-03-003 |
| US-WM-004 |
As an operator, I want threshold bands and breach markers, so that I can understand risk quickly. |
P1 |
MVP 1 |
PARTIAL |
Safe range is visible; breach points link or relate to alerts where available. |
FR-03-004 |
| US-WM-005 |
As a technician, I want sensor status to show online/offline/error, so that I know whether readings are reliable. |
P0 |
MVP 1 |
PARTIAL |
Offline/error state is visible and can trigger alert flow. |
FR-03-005 |
| US-WM-006 |
As an authorized user, I want sensor history filters, so that I can inspect readings by pond, metric and time. |
P1 |
MVP 1 |
PARTIAL |
Results respect role/scope and filters. |
FR-03-006 |
| US-WM-007 |
As a domain owner, I want algae/ORP representation clarified, so that metrics are not mislabeled. |
P1 |
MVP 1 |
TBD |
Product decision confirms whether algae, ORP or separate metrics are used. |
OQ-02 |
6.4 EP-04 — Alerts And Notifications
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-AL-001 |
As an operator, I want alerts created when water metrics exceed thresholds, so that abnormal ponds are surfaced automatically. |
P0 |
MVP 1 |
PARTIAL |
Alert records pond, metric, value, threshold, severity and timestamp. |
FR-04-001 |
| US-AL-002 |
As an operator, I want alerts for sensor/device connectivity issues, so that missing telemetry or failed equipment is visible. |
P0 |
MVP 1 |
PARTIAL |
Connectivity issue creates alert or clear error state; recipients are scoped. |
FR-04-002 |
| US-AL-003 |
As a user, I want to filter alerts, so that I can focus on relevant issues. |
P1 |
MVP 1 |
PARTIAL |
Filters include type, severity, farm, pond, status and time; data is scoped. |
FR-04-003 |
| US-AL-004 |
As a user, I want alert lifecycle states, so that ownership and progress are clear. |
P0 |
MVP 1 |
PARTIAL |
New, accepted/acknowledged, in progress and closed states are tracked with actor/time. |
FR-04-004 |
| US-AL-005 |
As a technician, I want to acknowledge alerts, so that others know I am handling the issue. |
P1 |
MVP 1 |
PARTIAL |
Acknowledgement updates status and activity timeline. |
FR-04-005 |
| US-AL-006 |
As an operations lead, I want overdue alerts escalated, so that serious issues are not missed. |
P1 |
MVP 2 |
PARTIAL |
Escalation follows configured SLA once timing rules are approved. |
FR-04-006, OQ-07 |
| US-AL-007 |
As an operator, I want rule-based or AI handling suggestions, so that I know the next safe check/action. |
P2 |
MVP 2-4 |
PARTIAL / PLANNED |
Suggestion includes source/rule label and does not trigger automatic dangerous action. |
FR-04-007, AI-05 |
6.5 EP-05 — Feeding Management
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-FD-001 |
As a technician, I want to enter feeding by session, so that daily feed usage is recorded. |
P0 |
MVP 2 |
PARTIAL |
Record includes feed type, amount, time, pond/crop, user and notes. |
FR-06-001 |
| US-FD-002 |
As a technician, I want to record feeding response, so that future decisions reflect shrimp behavior. |
P1 |
MVP 2 |
PARTIAL |
Response supports strong/weak/remaining feed and is visible in history. |
FR-06-002 |
| US-FD-003 |
As an owner, I want feeding history by day, week and crop, so that I can review feed consumption. |
P1 |
MVP 2 |
PARTIAL |
Totals and details are filterable by pond/farm/time. |
FR-06-003 |
| US-FD-004 |
As an operator, I want warnings when DO/pH is unsafe for feeding, so that I can avoid risky feeding decisions. |
P0 |
MVP 2 |
PARTIAL |
Warning appears during entry when thresholds are breached; thresholds are configurable/TBD. |
FR-06-006, OQ-03 |
| US-FD-005 |
As an owner, I want a daily feed suggestion, so that feeding can be optimized from pond/crop/environment context. |
P1 |
MVP 4 |
PLANNED |
Suggestion shows inputs, amount/range, confidence or rule label and fallback state. |
FR-06-004, AI-03 |
| US-FD-006 |
As an operator, I want per-session feed and time-window suggestions, so that feeding is easier to schedule. |
P2 |
MVP 4 |
PLANNED |
Session suggestions reflect crop/environment/history where available. |
FR-06-005, AI-03 |
| US-FD-007 |
As an operator, I want to override suggested feed with a reason where required, so that actual practice remains traceable. |
P1 |
MVP 2-4 |
PARTIAL |
Suggestion and actual amount are both preserved; reason rule is configurable/TBD. |
FR-06-008 |
| US-FD-008 |
As an owner, I want PCR/FCR once formulas are approved, so that feed efficiency can be assessed. |
P1 |
MVP 4 |
PLANNED / TBD |
UI shows calculated value only after formula approval; otherwise shows not configured. |
FR-06-007, OQ-01 |
6.6 EP-06 — Farming Logs And Productivity
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-LOG-001 |
As a technician, I want to enter manual environmental values, so that non-sensor observations are preserved. |
P0 |
MVP 2 |
PARTIAL |
Record includes pond, crop, date, values, user and notes. |
FR-07-001 |
| US-LOG-002 |
As a technician, I want to enter mineral records, so that mineral treatment history is complete. |
P0 |
MVP 2 |
PARTIAL |
Mineral type/category and quantity are captured; catalog is extensible. |
FR-07-002 |
| US-LOG-003 |
As a technician, I want to enter siphon records, so that pond-bottom maintenance is traceable. |
P0 |
MVP 2 |
PARTIAL |
Morning/afternoon/total siphon and notes are stored where applicable. |
FR-07-003 |
| US-LOG-004 |
As an owner, I want daily/weekly/crop log views, so that I can review operational history. |
P1 |
MVP 2 |
PARTIAL |
Filters by farm, pond, log type and time; scoped data only. |
FR-07-005 |
| US-LOG-005 |
As an operator, I want same-day edits before finalization, so that entry mistakes can be corrected. |
P1 |
MVP 2 |
PARTIAL |
Same-day edits work; post-finalization rule remains TBD. |
FR-07-006 |
| US-LOG-006 |
As a product owner, I want productivity formulas approved, so that productivity summaries are accepted. |
P0 |
MVP 4 |
TBD |
Formula and units are documented before metric is marked implemented. |
FR-07-004, OQ-08 |
| US-LOG-007 |
As an owner, I want productivity summaries by pond/day/crop, so that crop performance is visible. |
P1 |
MVP 4 |
PARTIAL / PLANNED |
Summary uses approved formula and handles missing data clearly. |
FR-07-007 |
6.7 EP-07 — Reports And Excel Export
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-RP-001 |
As an owner, I want a water monitoring report, so that water history and breaches can be reviewed. |
P0 |
MVP 2 |
PARTIAL |
Report filters by farm/pond/time and respects scope. |
FR-08-001 |
| US-RP-002 |
As an owner, I want a device report, so that runtime, commands and errors can be reviewed. |
P1 |
MVP 2 |
PARTIAL |
Report includes command history and error counts where available. |
FR-08-002 |
| US-RP-003 |
As an owner, I want a feeding report, so that feed usage can be reviewed by session/day/week/crop. |
P1 |
MVP 2 |
PARTIAL |
Report includes totals and omits PCR/FCR until formula configured. |
FR-08-003 |
| US-RP-004 |
As an owner, I want farming operation reports, so that environment, mineral and siphon activities are traceable. |
P1 |
MVP 2 |
PARTIAL |
Report includes manual logs and date filters. |
FR-08-004 |
| US-RP-005 |
As an owner, I want ticket reports, so that SLA and resolution history can be reviewed. |
P1 |
MVP 2 |
PARTIAL |
Report supports status/time/assignee filters and scoped data. |
FR-08-006 |
| US-RP-006 |
As a user, I want Excel export, so that I can share operational data outside AquaX. |
P0 |
MVP 2 |
PARTIAL |
Export excludes unauthorized data and records export history. |
FR-08-008, AC-07 |
| US-RP-007 |
As an owner or admin, I want scheduled weekly report emails, so that recurring reporting is automated. |
P2 |
MVP 2-3 |
PLANNED |
Schedule, recipients, timezone and content are configurable. |
FR-08-009 |
| US-RP-008 |
As a product owner, I want large exports to be background jobs when needed, so that reporting does not block users. |
P1 |
MVP 2 |
TBD |
Product/engineering confirm sync vs background export threshold. |
OQ-13 |
6.8 EP-08 — Tickets And Incidents
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-TK-001 |
As an owner or technician, I want to create a technical ticket, so that issues are tracked to resolution. |
P0 |
MVP 1 |
PARTIAL |
Ticket includes pond/device if relevant, severity, description and creator. |
FR-09-001 |
| US-TK-002 |
As a user, I want to attach images or videos to tickets, so that technicians have evidence. |
P1 |
MVP 1-2 |
PARTIAL |
Supported files upload securely and display in ticket detail. |
FR-09-002 |
| US-TK-003 |
As a user, I want ticket filters, so that I can find issues by status, type, assignee, pond and time. |
P1 |
MVP 1 |
PARTIAL |
Results respect scope and filters. |
FR-09-003 |
| US-TK-004 |
As an admin, I want to assign/reassign support technicians, so that each ticket has a responsible handler. |
P0 |
MVP 1 |
PARTIAL |
Assignee updates are tracked and notify the recipient. |
FR-09-004 |
| US-TK-005 |
As a technician, I want to accept, update and close tickets, so that progress is visible. |
P0 |
MVP 1 |
PARTIAL |
Status changes include actor, time and notes/resolution. |
FR-09-005 |
| US-TK-006 |
As an operations lead, I want ticket SLA tracking, so that delayed issues are visible. |
P1 |
MVP 2 |
PARTIAL |
Response and resolution timing are captured; escalation rules TBD. |
FR-09-006 |
| US-TK-007 |
As the technical team, I want email notification on ticket creation/escalation, so that issues are not missed. |
P0 |
MVP 1 |
PARTIAL |
Configured recipients receive email; failures are logged. |
FR-09-007 |
6.9 EP-09 — IoT Device Control
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-IOT-001 |
As an authorized user, I want to view pond devices and connectivity, so that I know what equipment is active. |
P0 |
MVP 1 |
PARTIAL |
Device list shows type, status, mode and connection state. |
FR-05-001 |
| US-IOT-002 |
As an authorized user, I want to turn devices on/off from web or mobile, so that I can respond to pond conditions. |
P0 |
MVP 1 |
PARTIAL |
Command is permission-checked, sent and tracked as pending/success/failed/timeout. |
FR-05-002 |
| US-IOT-003 |
As an operations owner, I want complete command history, so that device actions are auditable. |
P0 |
MVP 1 |
PARTIAL |
Log includes device, command, requester, request time, response and result. |
FR-05-003 |
| US-IOT-004 |
As an authorized user, I want manual/auto device mode, so that automation behavior is clear. |
P1 |
MVP 2 |
PARTIAL |
UI/API show current mode and allow permitted switch. |
FR-05-004 |
| US-IOT-005 |
As an admin, I want automation rules based on DO, temperature, schedule or thresholds, so that repetitive control can be optimized. |
P1 |
MVP 3 |
PARTIAL |
Rule has target, condition, priority, cooldown and enabled state. |
FR-05-005 |
| US-IOT-006 |
As an operator, I want timeout alerts when devices do not respond, so that failed commands are acted on. |
P0 |
MVP 1 |
PARTIAL |
Timeout creates/links alert and command history status. |
FR-05-006 |
| US-IOT-007 |
As a safety owner, I want auto mode conflict rules, so that automation does not override recent manual decisions unsafely. |
P1 |
MVP 3 |
PLANNED / TBD |
Manual override window and precedence are configured and tested. |
FR-05-007, OQ-04 |
| US-IOT-008 |
As an owner, I want energy/runtime analysis, so that I can reduce electricity cost. |
P2 |
MVP 3 |
PLANNED |
Runtime report or recommendation explains suggested schedule and source data. |
AI-06 |
6.10 EP-10 — Farming Handbook
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-HB-001 |
As a user, I want to browse approved farming articles, so that I can find operational guidance. |
P1 |
MVP 2 |
PARTIAL |
Only approved/visible content appears to non-admin users. |
FR-10-001 |
| US-HB-002 |
As a user, I want keyword search, so that I can find relevant articles quickly. |
P1 |
MVP 2 |
PARTIAL |
Search returns scoped/visible content and handles no-result state. |
FR-10-002 |
| US-HB-003 |
As a user, I want filters by topic, stage and metric, so that guidance matches my issue. |
P2 |
MVP 2 |
PARTIAL |
Filters can combine and return correct results. |
FR-10-003 |
| US-HB-004 |
As an operator, I want related articles from alert detail, so that I can check recommended handling steps. |
P2 |
MVP 2-3 |
PARTIAL |
Alert-detail content is based on configured mapping. |
FR-10-004 |
| US-HB-005 |
As a user, I want favorite articles, so that I can revisit important guidance. |
P3 |
MVP 2 |
PARTIAL |
Favorite/unfavorite persists per user. |
FR-10-005 |
| US-HB-006 |
As an admin, I want to create, edit, approve, archive and version articles, so that knowledge is controlled. |
P1 |
MVP 2 |
PARTIAL |
Version history is retained; archived articles are hidden from normal browse. |
FR-10-006 |
| US-HB-007 |
As an AI safety owner, I want chatbot-referenced articles preserved, so that AI answers remain auditable. |
P0 |
MVP 3 |
PLANNED / PARTIAL |
Referenced article cannot be hard-deleted after chatbot uses it. |
FR-10-007 |
6.11 EP-11 — Notifications
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-NO-001 |
As a user, I want in-app notifications for alerts, tickets and important updates, so that I can follow operational events. |
P0 |
MVP 1 |
PARTIAL |
Notification links to target entity and respects scope. |
FR-12-001 |
| US-NO-002 |
As a mobile user, I want push notifications, so that I can respond in the field. |
P1 |
MVP 1-2 |
PARTIAL / PLANNED |
Push opens detail only if user still has access. |
FR-12-002 |
| US-NO-003 |
As a user, I want to view, filter, mark read and delete notifications, so that notification center stays manageable. |
P1 |
MVP 2 |
PARTIAL |
Read/delete state syncs where supported. |
FR-12-004 |
| US-NO-004 |
As an admin, I want notification recipient and channel configuration, so that events route to the right people. |
P1 |
MVP 2 |
PARTIAL |
Changes affect future events and are auditable. |
FR-12-005 |
| US-NO-005 |
As an operations owner, I want duplicate notification prevention, so that users are not spammed by the same event. |
P2 |
MVP 2 |
PLANNED / PARTIAL |
Duplicate behavior follows debounce/config rule. |
FR-12-006 |
6.12 EP-12 — System Configuration
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-SC-001 |
As an admin, I want to configure alert thresholds by metric and scope, so that alerts match operational policy. |
P0 |
MVP 1 |
PARTIAL |
New threshold applies to future evaluation; precedence is documented. |
FR-13-001 |
| US-SC-002 |
As an admin, I want to configure device automation rules, so that auto control can be managed safely. |
P1 |
MVP 3 |
PARTIAL |
Rule condition/action/scope/enabled state are persisted. |
FR-13-002 |
| US-SC-003 |
As an admin, I want master data/catalog configuration, so that forms use consistent values. |
P1 |
MVP 2 |
PARTIAL |
Feed/mineral/device/ticket/alert catalogs are reusable where implemented. |
FR-13-003 |
| US-SC-004 |
As an admin, I want email template and recipient configuration, so that operational emails are maintainable. |
P2 |
MVP 2 |
PARTIAL / PLANNED |
Template supports variables and event recipient rules. |
FR-13-004 |
| US-SC-005 |
As an admin, I want ticket/alert SLA configuration, so that escalation timing is product-controlled. |
P1 |
MVP 2 |
PARTIAL |
SLA values affect future status/escalation calculations. |
FR-13-005 |
| US-SC-006 |
As a business owner, I want SaaS plan/account-limit configuration if commercialized as SaaS, so that subscription limits can be enforced. |
P3 |
Future |
PLANNED |
Requirement remains conditional until commercial model is approved. |
FR-13-006 |
| US-SC-007 |
As an admin, I want AI knowledge source and safety policy configuration, so that AI uses approved context only. |
P0 |
MVP 3 |
PLANNED |
Enabled sources/policies affect chatbot/recommendation context. |
FR-13-007 |
7. Non-Functional And Platform Stories
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-NFR-001 |
As a security owner, I want strict RBAC and scope checks on APIs, so that users cannot access other farms/ponds. |
P0 |
MVP 1 |
PARTIAL |
Negative permission tests pass for owner, manager and technician. |
NFR-05, Permission Matrix |
| US-NFR-002 |
As a security owner, I want sensitive data protected, so that tokens, passwords and private files are not exposed. |
P0 |
MVP 1 |
PARTIAL |
Passwords are hashed; tokens are protected; file access requires authorization. |
NFR-06 |
| US-NFR-003 |
As a product owner, I want dashboard performance targets, so that users can work during daily operations. |
P1 |
MVP 1 |
TBD |
Approved target is documented and measured. |
NFR-01 |
| US-NFR-004 |
As an operations owner, I want sensor API performance targets, so that telemetry views stay responsive. |
P1 |
MVP 1 |
TBD |
Approved target is measured under expected load. |
NFR-02 |
| US-NFR-005 |
As an operations owner, I want export performance strategy, so that long exports do not degrade the system. |
P1 |
MVP 2 |
TBD |
Large export strategy is confirmed and monitored. |
NFR-03, OQ-13 |
| US-NFR-006 |
As a mobile user, I want basic offline/low-connectivity behavior, so that field entry is still usable. |
P1 |
MVP 2 |
PARTIAL / PLANNED |
Cache/pending sync behavior and conflict rule are defined. |
NFR-11, OQ-10 |
| US-NFR-007 |
As a QA lead, I want regression suites for auth/scope/reports/device/tickets, so that releases do not reopen critical gaps. |
P0 |
MVP 1 |
PARTIAL |
Automated or manual regression coverage exists for P0 flows. |
AC-01..AC-12 |
| US-NFR-008 |
As an operations owner, I want logs, monitoring and backup/runbook decisions, so that production can be supported. |
P1 |
MVP 1-2 |
PARTIAL / PLANNED |
SLO/RPO/RTO and runbook owners are documented. |
OQ-14 |
| US-NFR-009 |
As a release owner, I want planned vs implemented status visible in docs, so that expectations stay aligned. |
P0 |
MVP 1 |
CONFIRMED |
PRD/BRD/SRS/backlog use explicit status labels. |
BRD-010 |
8. AI Safety And Prediction Backlog
8.1 AI Chatbot And Recommendation Stories
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-AI-001 |
As a user, I want a chatbot entry point on web/mobile, so that I can ask operational questions. |
P1 |
MVP 3 |
PLANNED |
Chatbot is visible only to authorized roles and shows planned/unavailable state until backend exists. |
FR-11-001, AI-01 |
| US-AI-002 |
As a user, I want text Q&A based on handbook and authorized pond data, so that answers reflect my context. |
P1 |
MVP 3 |
PLANNED |
Answer uses approved sources and authorized context only. |
FR-11-002 |
| US-AI-003 |
As a user, I want to select pond context, so that AI can answer about the right pond. |
P1 |
MVP 3 |
PLANNED |
Pond selector only lists authorized ponds. |
FR-11-003 |
| US-AI-004 |
As a user, I want image analysis for shrimp, water, feed tray, pond bottom or equipment, so that I can get a preliminary assessment. |
P2 |
MVP 4 |
PLANNED |
Output is labeled preliminary and suggests next checks/KTV fallback where needed. |
FR-11-004, AI-02 |
| US-AI-005 |
As a user, I want AI responses to show confidence and references, so that I can judge reliability. |
P0 |
MVP 3 |
PLANNED |
Response includes confidence/uncertainty and source references when applicable. |
FR-11-006 |
| US-AI-006 |
As a user, I want AI to suggest creating a ticket or contacting KTV when risk is high, so that serious cases are escalated. |
P0 |
MVP 3 |
PLANNED |
Low-confidence/high-risk response shows fallback action. |
FR-11-007 |
| US-AI-007 |
As a user, I want conversation history, so that I can review prior guidance within my scope. |
P2 |
MVP 3-4 |
PLANNED |
History is scoped and follows retention policy. |
FR-11-008 |
| US-AI-008 |
As a product owner, I want helpful/not-helpful feedback, so that AI quality can improve over time. |
P2 |
MVP 3-4 |
PLANNED |
Feedback is stored with response metadata. |
FR-11-009 |
| US-AI-009 |
As a security owner, I want AI authorization before context assembly, so that unauthorized pond data cannot reach the model. |
P0 |
MVP 3 |
PLANNED |
Unauthorized context requests are rejected before model invocation. |
FR-11-010 |
| US-AI-010 |
As an owner, I want rule-based alert recommendations before full AI if needed, so that MVP can provide safer early guidance. |
P1 |
MVP 2-3 |
PARTIAL / PLANNED |
Rule-based output is labeled, configurable and auditable. |
AI-05 |
| US-AI-011 |
As an owner, I want AI energy optimization suggestions, so that device runtime can be reduced safely. |
P2 |
MVP 3-4 |
PLANNED |
Suggestion includes source data, confidence and no automatic command execution. |
AI-06 |
| US-AI-012 |
As an owner, I want AI growth/productivity assessment, so that I can compare crop progress with expectations. |
P2 |
MVP 4 |
PLANNED |
Assessment explains contributing factors and missing data. |
AI-04 |
8.2 AI Prediction Stories
| ID |
User Story |
Priority |
MVP |
Status |
Acceptance Criteria |
Trace |
| US-AIP-001 |
As an owner, I want water quality trend prediction, so that I can act before values become unsafe. |
P1 |
MVP 3 |
PLANNED |
Prediction shows horizon, trend/risk, latest data timestamp and recommended action. |
AIP-01 |
| US-AIP-002 |
As an operator, I want alert risk prediction, so that preventive checks can happen before threshold breach. |
P1 |
MVP 3 |
PLANNED |
Output shows probability/risk band, likely cause and preventive recommendation. |
AIP-02 |
| US-AIP-003 |
As an owner, I want shrimp health risk prediction, so that suspicious crop conditions are escalated early. |
P2 |
MVP 4 |
PLANNED |
Output includes risk band, missing data note and KTV inspection suggestion. |
AIP-03 |
| US-AIP-004 |
As an operator, I want feed need prediction for the next day/session, so that feed planning is easier. |
P2 |
MVP 4 |
PLANNED |
Output includes feed range, confidence, reason and rule fallback. |
AIP-04 |
| US-AIP-005 |
As an owner, I want growth and productivity prediction, so that I can detect crop underperformance. |
P2 |
MVP 4 |
PLANNED |
Output includes forecast, productivity risk and contributing factors. |
AIP-05 |
| US-AIP-006 |
As an owner, I want harvest timing prediction, so that harvest planning can begin earlier. |
P3 |
MVP 4 |
PLANNED |
Output includes harvest window, confidence and required validation data. |
AIP-06 |
| US-AIP-007 |
As an operator, I want device/energy risk prediction, so that equipment can be inspected before failure or high cost. |
P2 |
MVP 3-4 |
PLANNED |
Output includes failure/energy risk, inspection recommendation and schedule suggestion. |
AIP-07 |
| US-AIP-008 |
As an AI owner, I want prediction backtesting before production, so that prediction quality is known. |
P0 |
MVP 3-4 |
PLANNED |
Historical evaluation exists before production-ready status. |
AI Safety |
9. Open Decisions And Blockers
| ID |
Decision / Blocker |
Impacted Stories |
Owner |
Priority |
| OQ-01 |
Approved PCR/FCR formula. |
US-FD-008, US-RP-003, US-AI-012 |
Domain/Product |
Blocker |
| OQ-02 |
Algae vs ORP metric definition. |
US-WM-002, US-WM-007 |
Domain/Product |
High |
| OQ-03 |
Threshold precedence by global/farm/pond/shrimp type/stage. |
US-AL-001, US-SC-001, US-FD-004 |
Product/Domain |
High |
| OQ-04 |
Automatic device control policy and user confirmation rules. |
US-IOT-005, US-IOT-007, US-AI-011 |
Product/Tech |
Blocker |
| OQ-05 |
Maximum devices/sensors per pond. |
US-FP-006, US-IOT-001 |
Product/Architecture |
High |
| OQ-06 |
Production IoT push/pull model. |
US-WM-005, US-IOT-002 |
Product/IoT |
High |
| OQ-07 |
Technical supervisor/escalation recipients. |
US-TK-007, US-AL-006 |
Product/Ops |
Medium |
| OQ-08 |
Productivity measurement method. |
US-LOG-006, US-LOG-007, US-AI-012 |
Domain/Product |
High |
| OQ-09 |
Siphon units and evidence requirements. |
US-LOG-003, US-RP-004 |
Domain/Product |
Medium |
| OQ-10 |
Offline sync conflict rule. |
US-NFR-006 |
Product/Mobile |
High |
| OQ-11 |
AI provider/model/knowledge sources. |
US-AI-001..US-AIP-008 |
Product/AI/Security |
High |
| OQ-12 |
Retention policy for telemetry, audit, files and AI history. |
US-AI-007, US-TK-002, US-NFR-008 |
Security/Ops |
High |
| OQ-13 |
Large report sync vs background strategy. |
US-RP-008, US-NFR-005 |
Product/Backend |
High |
| OQ-14 |
Production SLA/SLO, RPO and RTO. |
US-NFR-008 |
Product/Ops |
High |
10. Definition Of Ready And Definition Of Done
10.1 Definition Of Ready
A story is ready for implementation when:
- role and user value are clear;
- acceptance criteria are testable;
- API/data dependencies are identified;
- role/scope rules are known;
- required product/domain decisions are not blocking;
- design/UI expectation is available where frontend work is required;
- test strategy is clear for P0/P1 stories.
10.2 Definition Of Done
A story is done when:
- implementation is complete on required surfaces;
- backend authorization and scope checks are enforced;
- validation and error states are handled;
- audit/logging exists for sensitive actions where required;
- tests or QA cases cover happy path and key negative cases;
- documentation status is updated from
PLANNED/PARTIAL when applicable;
- no known P0/P1 regression remains open.
10.3 Extra Done Criteria For AI Stories
AI stories also require:
- approved input context contract;
- authorization before context assembly;
- confidence/uncertainty behavior;
- source reference behavior where applicable;
- prompt/context/output metadata logging;
- fallback/escalation behavior;
- no automatic dangerous action without confirmation and authorization;
- tests for missing data, stale data, low confidence and unauthorized context.
11. Traceability
| Backlog Area |
Source Reference |
| Product scope and functional requirements |
01_PRD — Product Requirements Document.md |
| Business requirements and process flow |
02_BRD — Business Requirements Document.md |
| Software requirements, MVP mapping and acceptance criteria |
03_SRS — Software Requirements Specification.md |
| Role/scope rules and permission gaps |
05_Permission Matrix.md |
| Roadmap sequencing |
01-product/roadmap.md |
| Data model grounding |
04_ERD — Database Design.md |
| Testing follow-up |
06-testing/test-cases.md, 06-testing/regression-suite.md |
| Known documentation gaps |
DOCUMENTATION-GAPS.md |
12. Document History
| Version |
Date |
Author |
Changes |
| 1.0 |
2026-09-17 |
Product |
Created root product backlog from PRD, BRD, SRS, permission matrix and roadmap. |
End of User Stories — Product Backlog